As it is generally known, the World Wide Web (referred to as the “Web” herein) is a system for providing interlinked hypertext documents via the Internet. Through a Web browser executing on a local client computer system, a user can view Web pages obtained from remote server computer systems. Web pages commonly include a mark-up language such as HTML (HyperText Markup Language) or the like, and may contain various specific types of content, including text, images, videos, and other multimedia.
A Web application is an application that is accessed over a network by a user on a client computer system via a Web browser. AJAX (Asynchronous JavaScript and XML), refers to a group of inter-related Web development techniques used to create interactive Web applications. In order to increase responsiveness and interactivity of a Web page, AJAX operates by exchanging relatively small amounts of data between the client and server such that the Web page does not have to be reloaded each time there is a need to fetch data from the server. As a result, the Web page's interactivity, speed, functionality and usability are increased.
Web 2.0 is a broad term describing the growing use of various Web technologies to enhance creativity, information sharing, and collaboration among users. Web 2.0 related efforts have led to the development of Web-based communities and hosted services, such as social-networking Web sites, wikis, blogs, and folksonomies. Significantly, many Web 2.0 Web sites rely heavily on AJAX.
Modern AJAX/Web 2.0 applications often need the server to asynchronously send real-time events to clients. For example, an AJAX-based chat session requires the server to relay the chat text received by the server to multiple connected clients. Existing systems have employed an HTTP (HyperText Transfer Protocol) server to send messages to clients. In some existing systems, a client makes an HTTP GET request to the server, and the server keeps the request until an event is ready for the client. The server then responds to the client with the event. This type of “polling” enables clients to obtain asynchronous events. However, Web browsers that are compliant with HTTP 1.1 are restricted to having at most two HTTP connections to any given server. Dedicating one of the two permitted connections for a server to getting asynchronous events leaves only one HTTP connection for everything else. This may be acceptable in situations in which only one browser window is needed for a service/application provided by the server, but imposes limitations that may be problematic in many cases.
For example, a problem may arise when it is desired that a single client (e.g. a user's client computer system) have several browser windows or tabs open to a given server. The need to have several windows/tabs open at once may arise in various use cases, such as when a window/tab is needed for each of multiple chat sessions provided simultaneously through a server, each of multiple online meetings provided simultaneously through a server, etc. In existing systems, N different windows/tabs using the same server (e.g. chat server, meeting server, etc.) must somehow share one of the two HTTP connections allowed by the browser to the server. This is a significant problem, and there is currently no way for existing systems to share a single HTTP connection among multiple windows/tabs associated with a single server.
Several solutions have been attempted, but have fallen significantly short in one way or another. For example, non-HTTP approaches, such as direct sockets/protocols to the server, e.g. using an applet software component, or Adobe Flash multimedia technologies, have been used. However, the custom ports and protocols involved in such systems are often problematic, especially with regard to issues related to the use of typical firewalls and/or proxies.
Another previously attempted solution involved each window separately polling for its own updates. However, this approach is likely to create too much load on the server, even though most of the time no updates would be obtained.
In another previous technique, a single physical server is referred to by many different names (e.g. through wildcard DNS or defined subdomains), so that each request appears from the browser's point of view to go to a different server. This type of approach involves a difficult set up for administrators, and may not work on all networks. In addition, cross-domain issues associated with this type of operation that are considered to be a security risk, and accordingly it may not always work in future browsers.
Other existing systems have made low-level changes to browser settings in order to increase the number of connections allowed in the browser. This approach is also difficult, since it requires users to install some amount of digitally signed, trusted code, and must be done for each and every browser and the operating system.
In view of the various shortcomings of such previous solutions as described above, there accordingly remains a significant need for a simpler and better way of getting asynchronous updates from a single, specific server to multiple browser windows/tabs of a browser on a client.